In the current competitive business conditions, manufacturers and sellers of products seek to be as cost competitive as possible, while providing quick delivery of products that often must be customized. Thus, modern businesses desire a mechanism for obtaining the best prices, delivery dates and quality from their suppliers and distributors in turn. In the past sellers purchased the items they needed from suppliers by calling a number of suppliers to determine cost and delivery dates. This process is shown in FIG. 1, where supply chain partner 100 communicates with supply chain partner 110 individually by means of a phone or fax line 120. This method of procurement often proves to be time consuming and expensive. In order to become more competitive, sellers began to automate their supply chains in order to derive cost savings and better serve customers by improving the efficiency of the transactions between various supply chain partners. For reasons of implementation cost, only the largest companies in the supply chain process could automate transactions between supply chain partners. Typically such supply chain partners were only able to automate simple transactions such as purchase orders, invoices and payments. Moreover, such automation was done by automating the transaction process one individual company at a time. For example, if a company wanted to automate the process of purchasing products from a number of different suppliers, current system typically require the company to setup a mechanism for purchasing products with each individual supplier.
Electronic Data Interchanges:
Electronic data interchanges (EDI) have been used in the past by some companies to exchange transaction information with their supply chain partners. EDI is a standard format for exchanging business data, developed by the Data Interchange Standards Association and designated as American National Standards Institute standard X12. An EDI message contains a string of data elements, each of which represents one fact, such as a price or product model number, separated by a delimiter or character used to separate data items. The entire string is called a data segment and one or more data segments framed by a header and trailer form a transaction set, which is the EDI unit of transmission. A transaction set often consists of what would usually be contained in a typical business document or form. A problem with existing EDI solutions is that there are large set up and maintenance costs associated with EDI. For example, each company that wishes to communicate with another company using EDI must setup a connection with that company in order to establish an EDI connection to that company. Thus, if a company has 100 suppliers and 50 distributors, the company is required to setup 150 different EDI interfaces. This process is cumbersome and requires a prohibitive number of resources in order to adequately implement. In addition, EDI messages are static, batch messages that do not permit interactive business processes to be conducted in real time. EDI protocols do not establish a standard mechanism for linking a series of messages in a predefined logical workflow sequence over a period of time in order to implement a business process. Thus, there is a need for a system that requires substantially less resources for a company to implement, and that permits business processes comprised of multiple messages linked by a logical workflow to be managed over time. For example, there is a need for a cost effective way for supply chain partners to communicate and exchange business transaction information, and to structure processes using this information that are linked by workflows and managed over time. The lack of standardized electronic business interfaces in supply chains has created many difficulties for manufacturers, distributors, resellers, and end-users who are attempting to automate business transactions. The problem is particularly acute for supply chain partners trying to use the Internet as a business-to-business commerce tool. For example, some of the problems typically encountered include the following:
1. Manufacturers use complex processes to determine inventory levels and availability across the supply chain at any point in time that are often little more than guesses because there is no agreement on how part numbers are defined or how to make inventory inquiries of suppliers through a standard interface.
2. Manufacturers have no automated way of comparing vendor prices and availability.
3. Distributors, who provide technical support to their resellers on thousands of items, are concerned with a lack of product information standards that makes the distribution of such information expensive and difficult.
4. Resellers must maintain different ordering and return procedures and system interfaces to each distributor and direct manufacturer with whom they trade.
5. End-users have no way of ordering items or confirming orders and delivery dates through uniform templates and must revert to older procedures such as calling suppliers with orders.
6. None of the users has any way of checking for errors that may be present in their requests or in the responses to their requests.
Currently available transaction systems do not fully automate business transactions and do not facilitate transactions between multiple parties. The time and cost wasted by the need for manual exchange of business information and transactions by phone and fax results in lost or incorrect orders, late deliveries, high clerical and labor costs, excessive buffer and obsolete inventory costs, and low customer loyalty and retention. Moreover, currently available transaction systems only permit the transmission and exchange of static batch messages. An effort has been made to overcome these problems by several organizations in different industries. An example of such an organization is RosettaNet™, an independent, self-funded, non-profit consortium formed in 1998 for the development of supply chain automation standards and guidelines. These standards serve to align processes between supply chain partners for automatic, system-to-system exchange of business information and transactions, with a number of transactions between a first partner and a second partner. RosettaNet™ functions through business processes known in RosettaNet™ parlance as PIPs (Partner Interface Process), where a PIP is a sequence of standardized transactions to perform a particular business function, such as a product inquiry or a purchase. The PIPs specify the activities for each trading participant and allow for multiple transactions between one partner and another linked together in sequence. PIPs are designed to be performed in real time. In order to use the RosettaNet system, a business process is modeled in terms of a PIP, which is defined in two data dictionaries that provide technical specifications for products and business properties, including transaction properties, supply partner data and most business related activities. For example, a PIP may include all of the information needed to introduce a new product to another partner, gain approval and update the partner's system with the new product information.
Many PIPs require trading partners to exchange multiple messages in a defined sequence within specified time limits, with the combined interactive message exchanges comprising a complete business process. These PIPs and similar business process standards are different from EDI messages in that they are not simply static, one-time batch messages, but instead comprise a sequence of messages linked by a logical workflow and occurring in a predefined sequence over a period of time. This linkage of multiple interactive messages over a period of time enables complex business processes to be concluded between parties that cannot be accomplished through transmission of a single message or even a sequence of messages not linked by a logical workflow.
RosettaNet™, while an advance, suffers from two major deficiencies. First, RosettaNet™ only provides for one-to-one type transactions. There is no provision for transactions involving more than two parties. Consequently, there is no way to compare suppliers or integrate a number of dependent transactions with different suppliers. RosettaNet™ does not provide a way for a seller to gain access to real time information on the status of the seller's entire supply chain. RosettaNet™ does not provide for the deployment of PIPs throughout an entire supply chain, with the same PIPS used by all of the supply partners. Moreover, RosettaNet™ does not facilitate the exchange of data between the various members of the supply chain. There is also a need to avoid the intensive, custom efforts associated with multiple connections to individual computer systems. Second, RosettaNet™ does not provide a mechanism for monitoring and managing the business processes over time to insure that a business process is successfully completed between trading partners.
Due to the limitations of current systems, there is a need for an electronic business system that facilitates the implementation of supply chain processes through the exchange of messages linked in a logical workflow and occurring over time. There is a need for a single, seamless, process infrastructure to manage these messages and processes and the ability to integrate those processes with other trading participants. There is also a need to avoid the intensive, custom efforts associated with multiple connections to individual computer systems.